The ongoing 1.3 update epic

[FlowerChild]

It's amazing how tiny things can often be the biggest pain in the ass:

I was just playing around with breeding some animals through throwing wheat on the ground. Well, it turns out this gets weird real quick.

The functionality works just fine mind you. The animals go into breeding mode, and a baby pops out a short time later. However, particles are the problem.

See, as far as I can tell, when you right click with wheat, that happens on the client, so it knows locally that the animal has gone into breeding mode, and the hearts start popping out. However, AI, and thus the code that picks the wheat up off the ground, exists on the server, so they eat it, but no hearts come out because the client is oblivious that they are in love mode.

Also, no packets exist for communicating that kind of information, because it isn't needed by vanilla behavior. So, just to get the bloody hearts, looks like I need to write a custom packet handler ;)

Same with placenta and the birthing particles actually. The client isn't actually aware of the "birth", it's just notified that a new entity has spawned at a particular location, which is the same thing that happens when a chunk is loaded, or what have you. As far as I can tell, there's no particular birth effect.

So yeah, I've said it before, and I'll say it again: this is going to take awhile :)

[Panda]

Thats fine by me theres not a thing wrong with btw 1.2.5 for the time being =]

[Ethinolicbob]

-snip-

I am not sure if I am following this properly and am at work and unable to check this out.
Would that not mean that while in a game, if you have one client feed an animal the other client(s) will not see that said animal is in love mode?

Edit: in case it is unclear I am talking about vanilla

[FlowerChild]

I am not sure if I am following this properly and am at work and unable to check this out.
Would that not mean that while in a game, if you have one client feed an animal the other client(s) will not see that said animal is in love mode?

Huh. That's actually a very interesting point. If someone with access to a 1.3 mutliplayer environment could test that out, I would be very interested in hearing the results.

If I am correct, you are right in that it shouldn't show up. If it does show up, I may have missed something in looking through the code.

[jakerman999]

Edit: Didn't.

[Ethinolicbob]

-snip-

Dude don't offer programming suggestions. Just don't.

[Ethinolicbob]

Got home checked it out. No hearts on the foreign client.
Seems if you do your own packet handler you are passively fixing vanilla bug(s).

Another (not relating) bit of interesting I found while doing this.
If you log into a LAN game with the same username (or by both not defining a name in offline mode) it will bump the other player off. In this case it bumped the host which resulted in bumping the server.

That would cause so much havoc in a big LAN party with one malicious person.

[FlowerChild]

Got home checked it out. No hearts on the foreign client.
Seems if you do your own packet handler you are passively fixing vanilla bug(s).

Damn, I was hoping I was wrong :)

Thanks for checking it out and verifying though man. It was a good theory.

EDIT: I think I'm actually going to triage this one for the first pass. The functionality is working, it's just the display that's not fully active at present (no hearts or birthing particles). If I spend hours resolving something like this now, it's just going to demoralize me, whereas if I come back to it later once the bulk of the mod is in working order, it will be much less tiresome to resolve these small but involved issues one at a time.

Yeah, I think that's the best course of action. I'll note this one down to be addressed at a later date.

[Ethinolicbob]

If you need any other vanilla server-client interaction tested I still have it setup and am available sporadically for the next hour or 2

[FlowerChild]

If you need any other vanilla server-client interaction tested I still have it setup and am available sporadically for the next hour or 2

Nah, it's cool man. Thanks. Honestly, the way things are working internally now, I don't think there's much difference between running SSP and LAN, other than not being able to test simultaneous actions from 2 clients.

That's in no way an indication that the first release will be LAN enabled. Testing those kinds of interactions will definitely be important down the road, but like above, I don't want to get bogged down in those kinds of details right now.

I will be a lot happier (and I'm sure a lot of others will be too) when I have the mod working as it did pre-1.3. Once I get that out of the way I can move on to addressing the rest of the issues without this huge mass of work hanging over my head.

[Ethinolicbob]

Yeah. Realised that it won't be available for Multiplayer. Figured I would offer anyway in case you wanted to quickly figure out which specific vanilla interaction is client based or packeted from server. Either way I am likely to do it anyway when I stop procrastinating and start being productive.

My mind cant quite fit & internalise the whole damm code like yours seems to. I usually start with isolation testing to figure where stuff goes wrong.
That pretty much sums up my entire job...

[FlowerChild]

My mind cant quite fit & internalise the whole damm code like yours seems to. I usually start with isolation testing to figure where stuff goes wrong.

Well, I don't really. The trick I find is to deal only in very broad strokes at the high-level, otherwise you become overwhelmed by the details in something that is too massive to fully conceptualize all at once.

Then, I tackle the underlying systems one at a time, poking and prodding at them only as they immediately concern me. That slowly fills in my higher or medium level understanding of what's going on.

You'll notice I'm devoting a lot of attention to compartmentalizing my tasks right now. That's because I know very well that this will quickly become overwhelming otherwise.

Also keep in mind that while I primarily consider myself a designer, I've fully architected a few commercial games in the lead programmer role, including their multiplayer components. This gives me a general high-level understanding of how these things work, even if the low level details vary from game to game. So yeah, a certain amount of it just comes down to experience, and getting used to dealing with massive projects at a high level in a manner that doesn't fry your brain :)

[Ethinolicbob]

Appreciate the insight man.
I gleaned a lot more from that than you may realise.

[akantorJojo]

cant remember this was alredy asked... but just to get it clear:
the EXTENDED-BLOCK-IDs was not in the 1.3.1 update right? we still have to wait for this!?

[Eriottosan]

No, they weren't in 1.3.1. I think this was covered a while back in the MC news thread. I think Mojang are going with a new string based system in the future, but the effect is the same in that there are more blocks able to be added. The hope is that this will be included with the Modding API in 1.4, but we won't know till we get there.

However, I'm not sure this is particularly relevant to this discussion, as it is now more a following of FC's progress updating, and previously was a thread on 1.3 discoveries, not what was left out.

[RaustBlackDragon]

So what makes the custom packet necessary? Does that mean I'd need to send custom packets for every single one of my dogs' abilities/stats? That scares me. Even if you were to implement a hook system, It certainly wouldn't be compatible with the hook system forge will inevitably implement to fix this, so I'm concerned that I'll have to maintain two copies of the codebase, one for BTW and one for Forge.

[DocHussey]

this might not be the correct place to ask, but does this mean with the connection of both client and servers that people such as myself, will not be able to play off-line? For example, I do not have a standard all-time Internet connection, so I bring my laptop to a friends house, and download the latest updates for both better than wolves and mine craft. With so much coming from server-side, off-line single player is effectively disabled right? Many apologies for possibly posting in the wrong place but if anyone will know the answer to this will be the people on this lovely forum.

**ED I T:Still working on using Dragon dictation, stupid spelling…**

[Elevatator]

-snip-

What? The Server runs internal.
Even in 1.3 you can play offline.

[natchu96]

this might not be the correct place to ask, but does this mean with the connection of both client and servers that people such as myself, will not be able to play off-line? For example, I do not have a standard all-time Internet connection, so I bring my laptop to a friends house, and download the latest updates for both better than wolves and mine craft. With so much coming from server-side, off-line single player is effectively disabled right? Many apologies for possibly posting in the wrong place but if anyone will know the answer to this will be the people on this lovely forum.

**ED I T:Still working on using Dragon dictation, stupid spelling…**

How fast does your laptop run minecraft right now? Can it handle stress?

'cause, as far as playing SSP is concerned, that things gonna be a server when you start up the game.

[FlowerChild]

So what makes the custom packet necessary? Does that mean I'd need to send custom packets for every single one of my dogs' abilities/stats? That scares me.

Mainly that I'm modifying an existing vanilla entity in a way that requires additional info to be communicated between client and server.

Even if you were to implement a hook system, It certainly wouldn't be compatible with the hook system forge will inevitably implement to fix this, so I'm concerned that I'll have to maintain two copies of the codebase, one for BTW and one for Forge.

As you know Raust, compatibility is not a focus for me. I may take steps to help with it later by investigating stuff like ModloaderMP or what have you, but for now, it's not a distraction I want to deal with in doing this port.

[RaustBlackDragon]

Understandable, I know how greatly we differ on the compatibility issue. At any rate, I'll stop fretting about it until I get a better grasp of how things stand, which should hopefully be soon.

[Sarudak]

As you know Raust, compatibility is not a focus for me. I may take steps to help with it later by investigating stuff like ModloaderMP or what have you, but for now, it's not a distraction I want to deal with in doing this port.

To be honest man I don't think anyone uses ModloaderMP anymore. I think Forge becoming incompatible was a deathstroke for them. The only major mod that doesn't require forge AFAIK is this one and it doesn't really cater to compatibility.

[FlowerChild]

To be honest man I don't think anyone uses ModloaderMP anymore. I think Forge becoming incompatible was a deathstroke for them. The only major mod that doesn't require forge AFAIK is this one and it doesn't really cater to compatibility.

Keep in mind that BTW add-on mods will require some kind of common-interface for all this stuff, otherwise it's going to be a complete cluster-fuck. I can either roll my own or use an existing solution like ModloaderMP.

Anyways, I will evaluate that later. For now I am special casing until I get everything working again and have a better idea of how everything works. My general programming policy is to special case first, then come up with a general purpose solution if needed, once I have a better understanding of all the problems involved.

[Sarudak]

To be honest man I don't think anyone uses ModloaderMP anymore. I think Forge becoming incompatible was a deathstroke for them. The only major mod that doesn't require forge AFAIK is this one and it doesn't really cater to compatibility.

Keep in mind that BTW add-on mods will require some kind of common-interface for all this stuff, otherwise it's going to be a complete cluster-fuck. I can either roll my own or use an existing solution like ModloaderMP.

Anyways, I will evaluate that later. For now I am special casing until I get everything working again and have a better idea of how everything works. My general programming policy is to special case first, then come up with a general purpose solution if needed, once I have a better understanding of all the problems involved.

Righto. As far as special casing and then generalizing I thought that was just good practice. I mean I know a lot of people who like to start designing a grand framework before they've even built out the cases that it'll actually be used for but that's silly and you end up wasting effort and usually not even fully covering all the use cases. Then again my boss does that sometimes... :P

[FlowerChild]

Righto. As far as special casing and then generalizing I thought that was just good practice. I mean I know a lot of people who like to start designing a grand framework before they've even built out the cases that it'll actually be used for but that's silly and you end up wasting effort and usually not even fully covering all the use cases. Then again my boss does that sometimes... :P

Hehe...maybe, but I don't think that's what they teach in school anymore. Over-architecting is definitely a problem that I see a lot of junior programmers develop, and it winds up just slowing down their development speed to a crawl while often creating an inflexible code-base that will ultimately need to be ripped apart and refactored at some point.

I tend to just apply the KISS principle at all stages, keep the code I do write modular and easy to swap out, and get the job done. You'll notice I've never felt the least bit compelled to do a complete rewrite of the BTW code-base, but I will go back from time to time to refactor sections of it when I see the necessity, and rarely will it break anything else.