Gondar wrote:

Because it's Cyan IP and made by a paid modeller (well, a few of them over the course of the game likely) to do character models, clothing, and animations.

It'd probably all fit under a bulk agreement, with the ages and other "3d models and textures". It's the fact that they are, indeed, 3d models and textures, that makes me wonder.

Besides, unless the toolset includes the rigging designs and so on that the modellers need to make clothing/animations/etc it won';t matter if it's theoretically open-sourced. It'll wait until it's reverse-engineered.


But we don't know the liscence agreement for both. It's possible I admit we'll get modifying rights assuming it stays in the game and isn't distributed outside of the game environment. I hope so.. because as I commented in another thread it's one thing not to be able to expand areas and add relto additions, but what if we found we had to rework all the Cyan ages to reduce lag by minimizing client load for physics and drawing? And if Cyan said no modifying the original content.. and the result was listen to them and have a load lag limit on Ae'gura.. or instead ignore them, modify it, and get our cones back AND 100+ people?


I'm being theoretical here.. none of us have seen the source, know what's involved, and know what the liscences involve.. but it's very likely we'll be able to find out tricks Cyan missed because they just didn't have the free time/money to strip down and rebuild parts of the engine, not while they had to get it running one way and as such because they had to have the ages work stable and anyways didn't have the luxury to have a build line sitting not-fully-done while it's in a beta, since there's another month's update to design/program/etc. And of course there's that we'll have far more programmers whacking away at it than Cyan could afford to hire even at their heyday.

Makes me wish I knew programming better than the little bit I can (and that's not even OOP). Instead I content myself to theorize from the sidelines and plot up stories and ages to try and convince others to help with one day

This (the bold) is how I feel. I don't think for a second that Cyan's artists and programmers are bad, but I know from experience that once a project goes from the research phase to production phase the hectic environment makes it difficult to go back and play catch-up.

Years or not, Uru is Cyan's first real-time 3D game and they had to learn from experience like the rest of us. (I loved realMyst, but I think it was more of a Plasma capabilities test.)

_________________
Can you withstand the gaze of the Eye of Eternity?

I've imported and played with Cyan's avatar rigging with Blender armature stuff.

Currently we have the capability to read and write almost every object type that MOUL has. There's not all that much we "can't" do as it is. It's just a matter of a person who knows what such and such variable does sitting down and playing around with them.

It'll be the same in OSMO (or whatever it'll be called). There won't be much we can't do. Only things that we "shouldn't" do.

So how I look at it is: Everything is possible. If you're legally allowed to do it is another matter.

_________________
Guild of Writers Councilor
PyPRP2 Developer
Plasma Hacker

Paradox wrote:

Rusty_Russell wrote:

Nalates wrote:

Actual lag is server side induced

Nalates, I see that as a splinter in your brain that needs to be removed. You aren't listening to people telling you what URU client lag was like in reality. That will have to be dealt with first.

No, Nalates is correct in the actual definition of "lag": which is a delay caused by network traffic.

What many people call "lag" in Uru (or "client-lag") is a graphical delay. not a network delay, so technically it is not "lag" in the original definition.

Many people consider any sort of delay to be lag though, and I'm of the mind that definitions can change over time.

I'll expand on this, cause I have first hand experience with MOUL and server client lag.

A short story, I spent several months when playing MOUL where I couldn't logon, Cyan eventually fixed this, but I could not finish Yeesha's journey, each time I jumped into the fissure I always returned back to Relto instead of the Cleft.

Details of why this had happened then i'll go over the workaround.
In Relto there is 2 link regions under the fissure, the first is the responder to tell the server that I want to link to the Cleft.
The second link region below that is a panic link region, which overrides any previous linking command that is in effect.
What happened is the server lag from my machine to the data centre was just a little too high, that when I jumped into the fissure the Link responder region would trigger a message to the server and wait for a response, usually less than 200ms of real time processed geometry triggers and response is sent back and forth. In my case the server response time was greater than this thus when the second region was triggered, ie the panic link region, it automatically overrid the responder link region response and therefore I returned back to Relto.

The workaround.
Short story, I had to force my computer (the client) to render real time geometry slower, so that the messages sent back and forth would happen without the override (client Lag).
I did this by using Prime95, which hogs CPU time, perfect, this reduced my FPS from a nominal 30 FPS to 5 - 10 FPS, and therefore I got the returned message to link to the Cleft before hitting the panic link region.

The fix, I changed my ISP so that I could take advantage of the Southern Cross Cable, and there is a minimum baud/ping to utilize this cable.


From Lontahv, PyPrp is amazing, we can do just about everything, and thanks to the hacking from Lontahv, Paradox, Andylegate, GPNMilano, Chacal and numerous others, we can also have particles, simple GUI's and by the looks of it, avatar poses.

PyPPrp development has slowed, as most of the development is heading into LibPlasma, and from there we hope to have a better PyPrp plugin for Blender, called PyPrp2

_________________
Lian-Li PC-V1000 plus II case, 600W powersupply, Striker Extreme motherboard, Intel Core2 Quad Q6600 CPU, nVidia 8800GTS 512, 2x1GB Corsair memory @ 800Mhz, 5.1 audio, wireless mouse, 200GB main hard disk.
Grogyan KI# 00793984 -> www.guildofwriters.com

I read that, Grogyan, and nodded. Made sense. I assume it's the same result as why there's a double-link in say the bahro caves.. you hit the link spot and as it's fading out hits panic-link and runs it instead.

But.. then I thought about it. Why does the game ignore the link command if the server doesn't reply? Is it that tethered to it? I mean, I can understand unloading stuff from some client considering it being the bottleneck, but wouldn't it be easier to quickly poll if you can get in during the start of the camera swoop or so, and run a link anyways, so that if it doesn't get permission it sends you to default link point (relto I assume) but if it does it bumps you to the cleft or wherever the link says to go?


Course I'm not a programmer.. but I'd think considering some of these problems that crop up with the load on the client, allowing it to do a little more assumptions on its own without having to tie it up into server waits *as well* as its own would help?
(Then again, client lag *did* fix the server lag issue. Huh. I suppose we just saw the practical results of that thread on the framerate cap )

_________________
You know, I wish we would learn Atrus loved the 1812 overture, and in turn we had a copy for our relto.
That's right, a canon canen cannon!

MOULa KI: #00027582
Welcome back all!

Actually there are very few actions that don't require a reply from the server. It has everything to do with client syncing. I guess some of it could be skipped when you are the only person in an age though.

The panic link is one of the few exceptions that don't require a server reply. That is why it can kick in before the fissure link and cause that nasty bug.

_________________
D'Lanor (ɹǝʇunч puǝƃǝן uɐqɹn)

♪ KI# 33949 ♪