Graal Forums

Graal Forums (https://forums.graalonline.com/forums/index.php)
-   Bug Report (https://forums.graalonline.com/forums/forumdisplay.php?f=193)
-   -   Windows v6 beta test (https://forums.graalonline.com/forums/showthread.php?t=134257598)

Tigairius 01-15-2011 07:35 AM

Made some large changes to the playerlist on Login 2.

Now profile windows will open at the center of your screen, likewise for PM windows and history.

Your Playerlist will save position now too if you have alwayson checked, so if you open it and move it to a certain spot on your screen, then when you log back into Graal, it'll open in that location. If anyone has any issues, please let me know.

Note: These features are only available on Login 2.

Mark Sir Link 01-16-2011 01:20 AM

On testbed, Personal/Mark_Sir_Link/GUITEST

On v5, using this style and changing the font in the profile is working just fine.

http://img834.imageshack.us/img834/1...1295133596.png

On v6, it is replacing the font with something else that doesn't appear to be in the window's blind skin nor is it my default font.

http://img141.imageshack.us/img141/5...1295133197.png

Happening to Jacob_Bald6225 also.

overridestylefont appears to work but isn't allowing the font color to be changed

Admins 01-16-2011 04:38 PM

It's using the font color defined in the wba file (Personality, ActiveTextR/G/B). You can set the profile.overridestylefont to override the font type, or set style = "" or "none" or so to get rid of the wba stuff in a sub-control.

Hmmm the window position things aren't working at all for me on login2, just seeing some windows shifting positions and the playerlist always appear at {0,0}

xXziroXx 01-16-2011 08:58 PM

PHP Code:

File downloadguigames_arcmessage2.png (size10128done
File download
guiblue_scroll_noback.png (size2543done
File download
loginserver_en.po not found
File download
login_gradient_blue.png (size309done
File download
graalv4title.png (size32000)...
File downloadgraalv4title.png (size64000)...
File downloadgraalv4title.png (size83319)...
File downloadgraalv4title.png (size83319doneFile downloadguigames_arcmessage2.png (size10128done
File download
verdanabd.ttf not found
File download
graalicon_big.png (size322done
File download
microsoft sans serif.ttf not found
File download
guiblue_scroll_noback.png (size2543done 

I get this every single time I open v6, it's rather annoying to download the same files over and over.

Also, and this is a bug that's been around on v5 for ages as well, when all the downloads are done it doesn't close down the window, and forces you to do it on your own. Which is annoying to say the least.

xXziroXx 01-16-2011 09:06 PM

Also, if you press Alt (without any modifier) in the main Graal window or an external one, the game freezes completely.

Skyld 01-16-2011 09:25 PM

Quote:

Originally Posted by xXziroXx (Post 1623238)
Also, if you press Alt (without any modifier) in the main Graal window or an external one, the game freezes completely.

I think that is because it is technically selecting the "window menu" (I am guessing if you press Alt and then when it is frozen press the down key, you will see the window menu appear).

xXziroXx 01-16-2011 10:00 PM

Quote:

Originally Posted by Skyld (Post 1623244)
I think that is because it is technically selecting the "window menu" (I am guessing if you press Alt and then when it is frozen press the down key, you will see the window menu appear).

Yeah, I know that much, was just hoping for it to be disabled somehow since the window menu doesn't really do much for Graal.

Skyld 01-16-2011 11:35 PM

Quote:

Originally Posted by xXziroXx (Post 1623253)
Yeah, I know that much, was just hoping for it to be disabled somehow since the window menu doesn't really do much for Graal.

This is probably more a Windows restriction I am guessing.

TSAdmin 01-17-2011 04:00 AM

Quote:

Originally Posted by Skyld (Post 1623284)
This is probably more a Windows restriction I am guessing.

I'm pretty sure it is. If there are no in-window menus available, it treats the ALT key as though you clicked the program icon in the top left of the title bar, which brings up the default "Move, Close, Resize," etc menu. I don't think programs themselves can disable that function. Google Chrome completely removed the title text and icon at the top of their window, yet you can still click that top left corner and achieve the same results.

-Ramirez- 01-17-2011 05:33 AM

Quote:

Originally Posted by Skyld (Post 1623284)
This is probably more a Windows restriction I am guessing.

It's a restriction of the rendering loop being in the same thread as the Windows message loop. I highly doubt Stefan is going to go through the potential multi-threading headaches to resolve this.

Crow 01-21-2011 06:29 PM

Quote:

Originally Posted by oo_jazz_oo (Post 1618886)
Just discovered something.

Now, I don't know much about particle emitters and stuff, but I found a problem with the snowfall on UN.

Basically, the script has the particle image changing every .5 seconds, so it changed the image for each new snowflake.
On v5, changing the image of the particle would only change it for new particles...

On v6, it is changing the image for every particle, ones already created, and new ones.

Not sure if this is a glitch, or if it was a glitch in v5.
The script changing the image of said particle is:
PHP Code:

findimg(200).emitter.particle.image temp.newimg


Quote:

Originally Posted by Stefan (Post 1620266)
It's an optimization, if you have only one particle template and only simple modifiers then it will try to draw all particles at once instead of drawing it one by one. You could eventually use several particle templates (emitter.particletypes = 2, emitter.particles[1].image = ...).

I don't think that using several particle types is a good solution to the problem your optimization creates. Consider an emitter for controlled text particles, each particle supposed to have a different text. How would you do that? Doesn't work quite as easy anymore with v6, does it?

fowlplay4 01-21-2011 11:10 PM

Quote:

Originally Posted by Crow (Post 1624634)
I don't think that using several particle types is a good solution to the problem your optimization creates. Consider an emitter for controlled text particles, each particle supposed to have a different text. How would you do that? Doesn't work quite as easy anymore with v6, does it?

The way I see the particle system (or how I use it), it's for situations where you don't want to devote a loop to display an effect. I.e: Sparkle-trail attached to player.

For what jazz is doing on UN he should only have to declare X~ types of particles and assign each particletype/snowflake a different image. I.e:

PHP Code:

emitter.particletypes 4;
for (
temp.0temp.emitter.particletypestemp.i++) {
  
emitter.particles[temp.i].image "snowflake_" temp.".png";


No need to constant loop and change the images every .5 second.

Could also just set continueafterdestroy to true, and destroy (hideimg) the particle image then re-create it with new values and none would be the wiser unless there's noticeable performance loss.

Crow 01-22-2011 05:51 PM

Well, currently, I have an emitter with a single particle type which emits text (which is always different) as a particle whenever certain conditions are met. The particle count can jump pretty high, too, so there's lotsa text sometimes. I can't really do that with multiple particle types, since I don't want to create a ton of them. With v5 it works just fine, changing the emitter.particle attributes before emitting the next particle. Using v6, all particles update when changing the attributes :(

Edit: Code example:
PHP Code:

//#CLIENTSIDE
function onCreated() {
  
with (findImg(200)) {
    
layer 6;
    
    
with (emitter) {
      
nrofparticles 1;
      
emitautomatically false;
      
      
with (particle) {
        
style "br";
        
zoom  0.9;
        
        
font "Arial";
        
textshadow  true;
        
shadowcolor = { 00};
        
        
speed 0;
        
lifetime 1;
      }
      
      
addLocalModifier("range"01"y""add", -48, -48);
      
addLocalModifier("range"0.51"alpha""add", -2, -2);
    }
  }
}

// called by something
function onStuff(s) {
  
findImg(200).emitter.particle.text s;
  
findImg(200).emitter.emit();



fowlplay4 01-22-2011 06:19 PM

Perhaps a emitter.particle.unique is in order to deal with those conditions.

Crow 01-22-2011 07:36 PM

Quote:

Originally Posted by fowlplay4 (Post 1624861)
Perhaps a emitter.particle.unique is in order to deal with those conditions.

Sounds good. Stefan, would you kindly implement this, please? :3


All times are GMT +2. The time now is 02:21 PM.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2025, vBulletin Solutions Inc.
Copyright (C) 1998-2019 Toonslab All Rights Reserved.