Split: 227 technical discussion

[ividyon]

If Person X is an advanced enough mapper that they actually have a desire for backwards compatibility and want it to happen, and yet they still want to use ArbitItem, they'll probably be smart enough to MyLevel it. It's completely unfair to assume that this class would be pose a major problem for "new mappers that want to maintain backward compatibility" because these two concepts do not align at all. And even then, this Mapper X could be notified of the problem post-release, replace the classes with myleveled versions and re-release it in like 15 minutes.

Smirftsch already acknowledged and confirmed several times that including these classes in stock packages wasn't ideal at all, and that he would've solved it differently today, no? 227 isn't a commercially funded project with a clear goal, analyzed and planned by a board of developers; it's a hobby project, during which there was a learning process and gathered experience for all people involved. Isn't that enough?

I consider the fact that such minuscule issues are always blown up into massive discussions a major lack of respect for the 227 project. You may mention on the sideline how everybody respects the project, the work that went into it, and its creators but, sadly, that does not help fight the impression these kinds of threads make on new and unexperienced users. I feel this is a gross mispresentation of the achievements and benefits of 227, particularly with silly phrases like "226 will work 100% of the time" flying around. Even I, as newbish 226 end user years ago, knew that I needed a bunch of packages like Nephthys and JCoopZ to even consider hosting a server, and I ran into plenty of stupid netcode bugs on the way, narrowly escaping hacks because I was either on friendly terms with or entirely unknown to people who could make them happen.

A bunch of things went wrong with 227; things that have been publicly acknowledged several times over, and things that could've been prevented by thorough beta testing before they made it into full releases - the latter being particularly baffling considering how many investigative and engaged users the community has, you two included - but many, many more things went right, which is something that I feel should be honored way more.

This community, and the 227 project in particular, could use a LOT more positivity. I hope that you can agree to this and aid with making it happen.

[bob]

Sort of unrelated ,But arbit item is available as a standalone for 225 already
http://wolf.tcpclan.net/projects/Unreal/ArbitItem.html
you could probably do some magic with export > import repace text in the t3d to remove the reverences in unreali.

[Mister_Prophet]

---
PS: Maybe 227j will be the last version, maybe not depending on eventually found bugs again, but in any case the times of fixing severe bugs and adding huge additions are very much over. I'm tired and if I would only do the things yet I really want to I'd probably stick for the moment just with OpenGL3/4 and working on OpenAL improvements and bugfixes if necessary. Bugfixing can be very funny but it can be also extremely annoying.
We added some nice native stuff yet for 227j, like support for multithreading when it comes to independently running stuff from fire and it also comes with a new OpenAL as said already, I found the reason for "bsp occlusion crashes" and "UED crashing while building huge spheres crashes" and although it can't be fixed 100% it's way more stable now. I cleaned up a lot of code and especially the Linux port needed some updates yet. There is a Linux ARM port now, to run a server on a Pandaboard with power consumption of not even 20W f.e.
Then again many more small things, but its very close to 227i yet and quite a few of the people taking part here still participate in testing ( in theory at least) so they could have a look any time - although the feedback is extremely low to non existent in the last months, so maybe I should take the opportunity now to act some critics as well here: If I get feedback in the first place there is no need to complain afterwards.

If it means anything there are people like me who look at 227 user made content but resist the plunge to develop for any of its assets simply because there is as of yet no final version. There are other things I don't see necessary, other aspects I like, but this is the big reason for me. My reasoning for this is simple; I need to know a platform is stable and secure for the long term. I cannot commit to a community patch that is liable to change with a passing season of bugtesting and internal improvements because that means I am indebted to patching a level or campaign for as long as updates to the patch are made. My situation prevents me the time to devote this effort post release, beyond say a first run string of updates if errors made on my end need to be implemented. It was different when Epic was making patches because the effects on SP were minor and there is a certain instance with an official patch that makes it so users simply have to play ball with changes. An example of this not being the case is UT patch 451 with oldskool-played SP games, most SP players using that platform know better to tangle. Of course it's also that I'm not young like I used to be when these games were fresh and updates were common. We are well passed the "ten years later" mark, which makes a final version of 227 just outright necessary for someone with my concerns, if I am to develop a level for it.

Knowing that patch 227 might reach a point where the letters stop and you and your team are comfortable saying, "okay that's it, we did good enough," makes the platform more attractive to someone like me. You'll find that there are a lot of experienced SP level designers/mod makers that have this view and a lot of people making their first big SP on 227 (now that it's available to them) that will see this fact proven to them until the day comes when the community has its final 227 patch. Unreal came out in 1998, at some point we have to stop "fixing" it, right?

[TheIronKnuckle]

Maybe Draco's concerns are more about what he's worried some people might do to his game and making it a trend more than what toolsets the 227 patch provides.

This pretty much summed up my stance towards smeshes for the longest time, but I've mellowed out and now I'm in the "It can't hurt to have more tools for mapping" camp.

My old irrational fear of smeshes probably just came from seeing the stock ones being overused in custom ut2kx maps; that I could never work out how to use them effectively in my own maps; that ut2k4 was a let down for me in so many ways and I was looking for things to blame (somehow smeshes copped it ); and finally that I love the challenge and results that can be achieved with BSP.

I can appreciate a good looking map done with BSP because I have a much better idea of how they did it and how damn hard and time consuming it would have been to do. Whereas my modelling knowledge is pretty much 0 so if I come across a smeshheavy map I don't really know what's going on. (And in the case of 2kx, if the map is loaded with stock meshes I don't really have any elevated respect for the mapper at all as it really comes across as a massive cut and paste job)

For those reasons, I always thought that bringing smeshes back to the classic engine would ruin the game. Thinking about it now, how fucking stupid could I have been? The millions of already existing maps out there aren't suddenly going to change. DM-Deck16][.unr will always be DM-Deck16][.unr. Nyleve falls isn't going to suddenly sprout thousands of different tree and jungle meshes. Also, in every example I've seen so far of 227 maps which use smeshes unreal atmosphere hasn't been ruined; it's been enhanced! See Turbomans test level

[Smirftsch]

If it means anything there are people like me who look at 227 user made content but resist the plunge to develop for any of its assets simply because there is as of yet no final version.
...
Knowing that patch 227 might reach a point where the letters stop and you and your team are comfortable saying, "okay that's it, we did good enough," makes the platform more attractive to someone like me. You'll find that there are a lot of experienced SP level designers/mod makers that have this view and a lot of people making their first big SP on 227 (now that it's available to them) that will see this fact proven to them until the day comes when the community has its final 227 patch. Unreal came out in 1998, at some point we have to stop "fixing" it, right?

I don't see it that strictly, obviously my personal biased opinion , since at least the later patches are having only a very few compatibility issues between each other, and the remaining things could be reworked easily, so it shouldn't be much work to update projects already started.
But your point of view is both very reasonable and very understandable. I agree, it's more than about time to finalize. I really think 227j will be this version, we found and fixed many of the remaining things we were not able to find before and it has been confirmed to be very very stable for server usage.

As far it concerns me only a few things are missing yet anyway, like an updated rendering system, as already requested, maybe even with HW lighting and it's advantages with shadows and bumpmapping (the last thing Epic intended to build in but never realized ), but this definitely doesn't have to be in a patch, it could be very well done in a standalone version.
Then the decal system is a bit flawed yet, especially when it comes to static meshes, but I see no feasible fix at the moment.

Then it's of course always possible that some bugs show up, for example in new ALAudio although it was been tested quite intensively (but again only by a limited number of testers).
So if there will be a possible 227k, then it can be done in a way that won't change anything which could cause a problem for projects and maps.

[ividyon]

You should probably enforce a feature-freeze on your next release and call it "227 final", then only release bugfixes in any subsequent 227 releases. If you should ever feel like there are enough new features to warrant a new patch, just call it 228 so that people can choose to stick with a stable, tested and finalized 227 if they want to.