RunUO Community

This is a sample guest message. Register a free account today to become a member! Once signed in, you'll be able to participate on this site by adding your own topics and posts, as well as connect with other members through your own private inbox!

.NET 4.0 Standard - VS 2010 Solution

Status
Not open for further replies.

fwiffo

Sorceror
machine crashes? yes, a lot, specially if you have timing issues.

Anyway there is some way to handle it correctly
 

fwiffo

Sorceror
well, It depends, I had no crashes at all for days, but I had to modify the way netstate works...it depends, It could even freeze all of a sudden without no apparent reason, but I am in the process of examining a solution I adopted, but I'm still testing it.
 

Two Wolves

Knight
What is the relationship between .NET 4.0 and A.I. 2.0 for us civilians? What is the future of A.I. 2.0 going to look like? Thank you for your time.
 

Pure Insanity

Sorceror
The new AI was abandoned from what I remember, because it relied on .net 4.0 and the rest of the dev team refuses to make .net 4.0 the new requirement. Probably some other issues too, but form what I hear about it...it really was amazing. Too bad we'll never see it.
 

ASayre

RunUO Developer
The new AI was abandoned from what I remember, because it relied on .net 4.0 and the rest of the dev team refuses to make .net 4.0 the new requirement. Probably some other issues too, but form what I hear about it...it really was amazing. Too bad we'll never see it.

The lack of "new AI" and .NET 4.0 not being the default aren't related in any type of actuality. There were a whole host of other issues... Such as rewriting a XAML Interpreter except treating this quasi-XAML as procedural and then compiling it all down to IL and using Emit directly to generate the code for it... before the higher functionality for it had been written. If this sounds like a confusing way to do things, you're not alone.

Back to the main thread, would y'all be willing to unequivocally confirm that the new Dynamic Save Strategy hasn't posed any problems in a production shard?
 

Vorspire

Knight
Back to the main thread, would y'all be willing to unequivocally confirm that the new Dynamic Save Strategy hasn't posed any problems in a production shard?

Pandora is running smooth using the new Framework 4.0 code, but we haven't activated the DSS specifically (by reducing the CPU requirement), though the save times are still back down to 10 seconds versus the 30+ seconds spent before the upgrade.
 

fwiffo

Sorceror
with dynamic save strategy only issue in my shard is on item on "no decay region" save...

For example, items decay at each save, even in they are in a regions where they shouldn't (the region is set so that no items could decay, for example it could be a house region, or a dungeon region), this thing could be fixed easy, by the way.
And everyone using dynamic save must take care of this.
 

ASayre

RunUO Developer
with dynamic save strategy only issue in my shard is on item on "no decay region" save...

For example, items decay at each save, even in they are in a regions where they shouldn't (the region is set so that no items could decay, for example it could be a house region, or a dungeon region), this thing could be fixed easy, by the way.
And everyone using dynamic save must take care of this.

Fixed.
 

ASayre

RunUO Developer
Quick question...if I update my copy, Mark won't go behind you and add all the .net 4.0 framework crap back. Will he? To be honest, I'm not completely sure why he did it last time.

Now with proof that the .net 4.0 problems were due to the implementation of the networking changes instead of the .NET Framework itself, I'm sure Mark will understand there's no reason now to stay on 2.0.
 

Pure Insanity

Sorceror
Dynamic save works great, just seems there are some issues with the new networking code. Mark reverted all changes, making 4.0 optional. Personally, I say their support is backwards. Making the new/better stuff optional, when the old legacy shit should be optional...
 

Vorspire

Knight
Then what 4.0 are being used? If Dynamic saving is buggy, and the networking code has issues?
It doesn't even matter what stock 4.0 features RunUO comes with, .NET 4.0 allows for developers to use much more efficient code when writing "scripts" for RunUO and we've already covered the performance gains during compile-time and run-time.
One of the reasons you don't realise this is because you're still learning 2.0
 

fwiffo

Sorceror
As a new user, and not as an experienced programmer, since this is supposed to be a hobby and a source of entertainment for me, I think that stopping from evolving is bad, I recently started reading more and more docs for .net 4, and forcing .net 2 is a bad idea (but, again, isn't SVN supposed to be used mainly by who knows what is doing? so, where are those noobs?).

Nonethless, speaking of me, our shard begun migrating from an old emu to runuo 1.0 or whatever it was (but this migration failed, there was no source of the core at the time, developers of the time stopped developing it too because of this..we were in need of it at the time, our old emu was too buggy), then to runuo 2.0rc2, but for about 3 years we suffered for the way it was, many many things has been changed, and almost anything is different now, but we updated core to recent changes, updated to support new clients, and used most of the things that .net4 can offer, me too, as an unexperienced programmer, as I said above, have begun reading and I've taken an advantage from the new core. We have also maintained the network code and debugged it, I think I've sent a patch to Asayre (that contains writing errors), we are still using it with many days of uptime without any crash/deadlock...but, anyway, there I am nobody, and for sure our shard is really different from osi/yours I think, I don't think there's still something left of the old code in scripts, said this, again, retaining .net 2 is a BAD idea IMHO, you're blocking active development from who is trying to learn the language, and who begins reading runuo code and finds it still uses old framework, will try other roads, finding skilled people that want to program for an old game like uo isn't easy, and when someone that couldn't loose too much time starts to see that this isn't something one wants before catching the notch and beginning to get amused...too bad, he/she will go away...

I think all of this could be done in reverse mode, make .net4 mandatory and .net2 optional, who want the old piece of software for sometime can still use it, but I think that .net2 is dead on an emu like this.

I hope at least that what I wrote is clear enough. :p
 
Status
Not open for further replies.
Top