Jump to content

Recommended Posts

Oh damn it... So the mod is broken for TvT games? Damn bis!

Not broken :) just more hardcore hahaha

  • Like 5

Share this post


Link to post
Share on other sites

BIS updated the sample character model (A3_Character_Example.p3d) to include the new hitpoints selections. So it's a matter of deleting the old points from the LOD and copy+pasting the updated LOD from the sample model.

Does this mean that any old mods are broken (not only RHS)? And you have to re-binarize all models with new model.cfg.

Share this post


Link to post
Share on other sites

Does this mean that any old mods are broken (not only RHS)? And you have to re-binarize all models with new model.cfg.

Indeed all uniforms/vests/helmets of all addons that came before nexus update will be broken (except for retextures of course, those do not modify bis models or configs). Not just RHS.

 

 

Got huge RPT spam.

This is all related.

Share this post


Link to post
Share on other sites

After patch 1.54 with weapons RHS stop magazine approach from other mods. Perhaps, broken and addon ASDG Joint Rails. :(

Share this post


Link to post
Share on other sites

After updating the spare tires are floating.

 

 

I believe that was an issue with ACE prior to 3.4.0 on 1.5.4. Update ACE and it should be fine.

Share this post


Link to post
Share on other sites

Indeed all uniforms/vests/helmets of all addons that came before nexus update will be broken (except for retextures of course, those do not modify bis models or configs). Not just RHS.

 

This is all related.

I found that other old mods with vest don't through such errors.

Share this post


Link to post
Share on other sites

I found that other old mods with vest don't through such errors.

If the said vest is just a model that inherited every value from a vanilla one with no actual config data, then yes, there don't through out errors

  • Like 1

Share this post


Link to post
Share on other sites

I found that other old mods with vest don't through such errors.

Were they new models? Or just re-textured vanilla vests? Because if its the second, they most probably inherit everything from them.

EDIT: Freaking ninjas haha  :ph34r:

  • Like 1

Share this post


Link to post
Share on other sites

Does this mean that any old mods are broken (not only RHS)? And you have to re-binarize all models with new model.cfg.

 

The changes I was on about there are only if the mod contains custom unit models, so probably only affects a handful of addons.

 

Vest, helmet, rucksacks etc. - other wearable models; don't include their own hitpoints LOD so should only have issue with the config changes.

Retextured BIS unit models (which form the majority of unit addons) will contain the new hitpoint selections unless someone retextured them by extracting the .p3ds from the game data and hex-editing them instead of using hiddenSelections.

 

The model.cfg hasn't been changed to my knowledge; only a few extra named selections in one LOD. But swapping the .p3d files for a new one would be something where you'd need the unbinarised MLOD source file for the unit model, and to repack the .pbo.

 

BIS released the updated source files that contained these hitpoints LOD changes when they were announced on the dev Branch months ago.

  • Like 1

Share this post


Link to post
Share on other sites

Do you think an RHS hotfix without new content but just for fixing issues provided by last patch could be expected soon?

Share this post


Link to post
Share on other sites

Do you think an RHS hotfix without new content but just for fixing issues provided by last patch could be expected soon?

no, the infrastructure just does not allow for this.

  • Like 2

Share this post


Link to post
Share on other sites

no, the infrastructure just does not allow for this.

The infrastructure thats great lol.
  • Like 2

Share this post


Link to post
Share on other sites

The infrastructure thats great lol.

What?

Our update system is programmed to push out updates to the servers with only 1 click.

Each time someone commits to the development repository, we have an automatic build machine building the pbos so we have ready-2-download files for testing. If we think the time for an update is due, all we (or rather Soul_Assassin) do is to push thos pbos to our public download server and create torrents too.

This makes it as easy as possible for us to publish an update, but hotfixes are only possible after a big update.

  • Like 5

Share this post


Link to post
Share on other sites

What?

Our update system is programmed to push out updates to the servers with only 1 click.

Each time someone commits to the development repository, we have an automatic build machine building the pbos so we have ready-2-download files for testing. If we think the time for an update is due, all we (or rather Soul_Assassin) do is to push thos pbos to our public download server and create torrents too.

This makes it as easy as possible for us to publish an update, but hotfixes are only possible after a big update.

 

Wasn't the whole point of this system in order to allow smaller, more frequent updates? It seems to be just falling back to where it was previously with the only releases being large releases.

 

Like most repository systems rely on branches etc to avoid issues like this so new public builds can be pushed out to solve new issues without needing to send unfinished content along with it. I mean most of the issues that have come from the past two builds are config tweaks which could have easily been hotfixed using any other system.

  • Like 2

Share this post


Link to post
Share on other sites

Wasn't the whole point of this system in order to allow smaller, more frequent updates? It seems to be just falling back to where it was previously with the only releases being large releases.

 

Like most repository systems rely on branches etc to avoid issues like this so new public builds can be pushed out to solve new issues without needing to send unfinished content along with it. I mean most of the issues that have come from the past two builds are config tweaks which could have easily been hotfixed using any other system.

We publish releases every 2-3 months, so more or less one each quarter. We postponed 0.4 because of the time 1.54 was bound to released. We know that it would break stuff, so we decided not to push it out sooner.

  • Like 4

Share this post


Link to post
Share on other sites

Wasn't the whole point of this system in order to allow smaller, more frequent updates? It seems to be just falling back to where it was previously with the only releases being large releases.

 

Like most repository systems rely on branches etc to avoid issues like this so new public builds can be pushed out to solve new issues without needing to send unfinished content along with it. I mean most of the issues that have come from the past two builds are config tweaks which could have easily been hotfixed using any other system.

I imagine it mostly exists to simplify the logistics of pushing builds for internal iteration and the fact that it also feeds the public release process is merely a useful by-product.

 

It's all very well being able to branch and merge but somebody still has to prioritize and execute those changes and then they would have to be tested separately removing test time from other features in the main branch. I can entirely understand why RHS don't want to get side-tracked by hot-fixing, especially given it's a hobby rather than work for which they're paid

  • Like 1

Share this post


Link to post
Share on other sites

Wasn't the whole point of this system in order to allow smaller, more frequent updates? It seems to be just falling back to where it was previously with the only releases being large releases.

 

Like most repository systems rely on branches etc to avoid issues like this so new public builds can be pushed out to solve new issues without needing to send unfinished content along with it. I mean most of the issues that have come from the past two builds are config tweaks which could have easily been hotfixed using any other system.

Its all very good and grand when your repository is mostly ascii files (code) and is maybe 100mb big. But when you are like us, with repos now reaching 10s of GB big, with mostly binary unmergable files it quickly can become a headache. Plus we already mentioned that 0.4 comes before the end of the year. Also they are not just config tweaks. Adding hitpoints to all of our wearable content takes some time too as we have a lot.

 

Plus the problem is rather not even on the development side of things. We actually have a test and release automation cycle as RedPhoenix explained that is self built and is rather not made to deal with branched hotfixes.

 

I do hope you can understand and wait the couple of weeks we need to deploy a new version. Everybody is already working overtime.

  • Like 6

Share this post


Link to post
Share on other sites

We publish releases every 2-3 months, so more or less one each quarter. We postponed 0.4 because of the time 1.54 was bound to released. We know that it would break stuff, so we decided not to push it out sooner.

Isnt there some other method - I'm not specialists but let me ask - if you create second "folder" named "fixes" next to the "Stable" you will be able tu push out the fixes too right?

Share this post


Link to post
Share on other sites

Isnt there some other method - I'm not specialists but let me ask - if you create second "folder" named "fixes" next to the "Stable" you will be able tu push out the fixes too right?

I wish it was so simple :)

  • Like 2

Share this post


Link to post
Share on other sites

Wasn't the whole point of this system in order to allow smaller, more frequent updates? It seems to be just falling back to where it was previously with the only releases being large releases.

 

Like most repository systems rely on branches etc to avoid issues like this so new public builds can be pushed out to solve new issues without needing to send unfinished content along with it. I mean most of the issues that have come from the past two builds are config tweaks which could have easily been hotfixed using any other system.

Yes, ideally we'd want more frequent updates, and we communicated that back in May. BUT:

1. Summer time is mostly for vacation time, you can't force people to spend their free time in front of a monitor

2. We are dependent on BI release schedule, as you have seen their 1.54 update changed how things work on more than 1 level, we have to adapt to that and implement the new systems, and that is for quite a good chunk for the existing 3d models.

 

In any case, expect a pretty hefty update for 0.4, both in content and file size, since a LOT of the p3ds are being updated.

 

As both Soul Assassin and RedPhoenix explained, the entire repro to build process is set in place in a certain way for a good reason (part of it being our own development test phase).

 

Please do understand that the update will come before 2016, and for that to happen everyone is working on it instead of planning for Christmas. There is no gain for either you or ourself if you keep pestering us about it.

If you encountered any bugs, please use http://feedback.rhsmods.org/instead of forums or facebook

  • Like 9

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×