Quote from: LigH on May 28, 2012, 10:59:40 am

You could try disabling GLSL.

Tried this and it crashed the client before it could finish loading. Deleted the line and reopened the client...may have made it worse?

it may be a good idea to clear the shadercache after changing that setting - from my experience not doing so and changing that setting may cause crashes/corrupt the cached shaders

What RlyDontKnow referred to was probably an already known issue with grass in relation to the Background Loader mode

nope, that one I already tracked down and fixed, I was curious whether it's loading or culling going mad there, but as it's not loading, it's most probably culling which doesn't make sense unless you have an undocumented config setting in your config that I added for testing purposes that forces a specific culler everywhere and have that set to default to enforce hardware culling.

now the big question is: why would culling be wrong?
that sector uses simple (software) frustum culling, so it's not driver related.
since it's not driver related and works everywhere else and there's no reason the position or bounding box of the grass would change in any way, it seems unlikely that's even the cause.

so... why else would it render incorrectly? I don't know :/

what you could do to help find the cause of the issue is:
1) try to add "PlaneShift.Loading.ForceCuller = crystalspace.culling.frustvis" to your planeshift.cfg ($HOME/.PlaneShift/planeshift.cfg) (just to be sure it's not a weird culler setting) - if it doesn't help, remove it again and do
2) set up glIntercept (with OneFrameOnly set to false in the config, instead hit the log key again after the grass re-appeared) so we could check the gl calls and see whether something is off there.
(note that I just recommend that as I have no idea what could possibly go wrong besied culling for you and because you seem to be the only one to have it (in other words: no dev/tester can reproduce it which makes it likely it's a hardware/OS/driver combination causing the issue))

add "Video.OpenGL.UseExtension.GL_ARB_shader_objects = false" to the planeshift.cfg

I guess the current problem of physical immunity is not really an issue of magic rules, even though a mage benefits even more from that than a warrior. We have seen this issue partly when all attacks were scaled to inflict less damage, which eliminated many one shot kills in both pvp and pvm. Now we have some high quality armor for even more protection, and a few buffs (loot/spell) that seem to be additive. My hope is that there are big changes to come with the combat enhancements, that the system of armor based defense loses some of its additive nature and that critical hits will be introduced that break through an armors weak spot. Balancing of magic against combat is another big problem that can be addressed once both fields work (e.g. no more infinite mana and mental stamina).

to name the issue more on a "cause" level: PlaneShift lacks rules developers - as already raised many times in the wish list and complaint department boards here. yes, most mechanics aren't very balanced, but there's a fix for it: go and try to make people who may be suited step up and have them apply to the team.

without someone dedicated working on rules, there sure won't be a perfectly balanced system anytime soon.

and on another note: yes, it's an *alpha*.
that means features get added/changed regularily requiring balancing adjustments and even a simple bug fix can cause balancing changes (see AoE spells  )
just think how it'd affect the mage<->warrior balancing when warriors actually get skills to use besides their simple standard attack

i.e. too much abuse.
it's not fun if someone builds a cage you cannot escape around you while you're afk or under the curse
or if people spam random items all over yliakum to climb up somewhere, etc.

Quote from: weltall on March 12, 2012, 01:12:08 pm

it wouldn't be a load problem much. putting all in the same map will avoid load. The real problem is that portals are more heavy as you need to render the scene in the portal and put it as a texture (portal series used some tricks to reduce weight but that's a cs side work in any case).

Is this really the case? [...]
If I'm standing outside Kada's looking in, I'm actually looking through a portal into a separate sector. Of course, you're the expert.

yes. sectors and loading zones are different things. loading zones consist (usually) of multiple sectors (often something like 3-10, but it's really whatever you want).

portals however do have some performance issues, but they shouldn't be an issue as long as you don't see many at once (to check it out, stand at harn and look towards east hydlaa so you also see temple and sewer entrance - that's why it's slow there )

e.g. the sewers consist of many smaller sectors all connected via portals and it's not an issue at all

to the actual point tho:
yeah, some spatial weirdness would be fun, but overdoing it with super weird labyrinths is a little over the top I think, it's already hard enough to find the DR exit for newcomers as it's now

and who would keep that up to date?
after all there's no way to programmatically know who's playing which plot with whom or such

and personally I doubt even anyone actively playing knows about all plots going on atm, so this seems a little... off imo.

You could certainly sing that for the holidays, but I might reccomend, talad did give to me
rather than talad gave to me, it rolls off the tongue better

or just make it "laanx gave to me"