----------------------------------- BioHazardousWaste Sat Feb 14, 2004 5:12 am Confusing Problem With View.UpdateArea (Era of War) ----------------------------------- As suggested I have been using the View.UpdateArea command to deal with graphics and create animations in Era of War. It was working nicely until I wanted the user to input a command. The problem is that the user cannot see what they are typing. I tried setting the window back to nooffscreenonly mode, but that screwed up the lines seperating the three sections of my window, and is not very nice switching the type back and forth so often. So I need to know what I can to do so that the user can see what they are typing. ----------------------------------- TheXploder Sat Feb 14, 2004 10:09 am ----------------------------------- I think the main reason is that View.UpdateArea updates only that one specific area unless you're typing within the View.UpdateArea you are not going to see it.... you could make another View.UpdateArea for the text... Now that I think about it... That's not the problem... It's becuse it doesn't do any updates while it gets an input... Try using fork... ----------------------------------- BioHazardousWaste Sat Feb 14, 2004 11:52 am ----------------------------------- Not exactly sure how that would work... could you give me an example please? ----------------------------------- Cervantes Sat Feb 14, 2004 12:09 pm ----------------------------------- if you were to use View.Update (no area part) does it work? I can't really think of why without seeing the code. You can PM me all or part of the code and I'll take a look :) ----------------------------------- TheXploder Sat Feb 14, 2004 12:24 pm ----------------------------------- no I tryed View.Update, it doesn't work, only way I found is this, but its so, slow, maybe gotta add some delay... ohh, ya, delay 15 works View.Set ("offscreenonly") var word : string process Get get word end Get process Update loop View.Update delay(15) end loop end Update fork Get fork Update ----------------------------------- BioHazardousWaste Sat Feb 14, 2004 12:30 pm ----------------------------------- Thanx man, that seems to work allright... you forgot to include an exit when statement :P, but I got that figured out. ----------------------------------- Cervantes Sat Feb 14, 2004 12:40 pm ----------------------------------- Xploder how could you be so cruel as to suggest processes....... they suck :P bio did you get it to work my way or xploder's cursed processes way? ----------------------------------- BioHazardousWaste Sat Feb 14, 2004 12:43 pm ----------------------------------- Xploder how could you be so cruel as to suggest processes....... they suck bio did you get it to work my way or xploder's cursed processes way? Xploder's cursed processes worked :P... but processes will lag the game up will they not? ----------------------------------- Cervantes Sat Feb 14, 2004 12:48 pm ----------------------------------- Yes, horribly. :? ----------------------------------- TheXploder Sat Feb 14, 2004 1:50 pm ----------------------------------- ok I think I know another way... use graphic text... and you can update that. I do know that processes suck, and I told you already. View.Update doesn't work because it waits for you to press enter, it doesn't update while you type, that is the problem... So getch might work, better... ----------------------------------- Tony Sat Feb 14, 2004 1:52 pm ----------------------------------- no no no :roll: what you need to do is create a console window. Basically just another distinct View.UpdateArea where text is displayed. You would just need to be able to minimize/maximize that area so it doesn't get in the way... Or keep it on the game screen with a timer. ----------------------------------- recneps Sun Feb 15, 2004 1:29 pm ----------------------------------- Tony's on to something there, you could have a separate window open var get:int:=Window.Open ("Title; Enter a command!;400;400") then just have the user input info into that window, like HL console :) (except its separate window) ----------------------------------- sport Sun Feb 15, 2004 3:03 pm ----------------------------------- Code: var get:int:=Window.Open ("Title; Enter a command!;400;400") will not work, because get is a predefined word so jus change get to any other word.[/quote] ----------------------------------- Cervantes Sun Feb 15, 2004 5:23 pm ----------------------------------- I don't think that's the best way to do it... that involves having to click twice (once to switch windows and once to click the button or whatever). Also it doesn't look that great. :eh: ----------------------------------- shorthair Sun Feb 15, 2004 10:03 pm ----------------------------------- Albert einstein didnt look that great , but he re defined physics , dude we need a working game not a pretty one ,thast why we belive in updates and fixes , letsnot get hooked on GUI when there is a game to be made ----------------------------------- BioHazardousWaste Mon Feb 16, 2004 1:51 pm ----------------------------------- dude we need a working game not a pretty one ,thast why we belive in updates and fixes Amen shorthair... but as for the idea, I think it will work. I tried this: Mouse.ButtonChoose ("multibutton") var mx,my,mbutton : int loop Mouse.Where (mx,my,mbutton) if mbutton = 1 then exit end if end loop put "X - Coords: ", mx , " " , "Y - Coords: ", my and it returned a negative value for Y when I clicked below the window... so could I not use the same thing? when the user clicks on the button on the second window, it will return a negative value, but I still know where the mouse is, so I can call the appropriate function. Yes? No? Maybe? ----------------------------------- Cervantes Mon Feb 16, 2004 3:39 pm ----------------------------------- Yes you can do that. I don't understand why no one thinks View.UpdateArea is good. The code that you sent me bio works fine once you make it all fit on the screen (ie. not having huge locates such as 37 and 48 (for the row). ----------------------------------- BioHazardousWaste Mon Feb 16, 2004 3:50 pm ----------------------------------- Both ideas seem to work fine, but the advantage that a second window has, is that it will be very easy to hide or show that window: e.x. if the user wanted battle statistics they could be put there (e.x. Hvy Tank missed, Light tank hit for 40 dmg). But that is later, I need to get the game made first ----------------------------------- Tony Mon Feb 16, 2004 5:12 pm ----------------------------------- actually having a council window run on the side with stats and messages would be really cool (easier to debug too)... the only problem would be the constant switching back and forth between the two... and say if the windows switch and the user clicks on the play window before windows switch back, output will end up in the wrong window :? ----------------------------------- BioHazardousWaste Mon Feb 16, 2004 6:05 pm ----------------------------------- actually having a council window run on the side with stats and messages would be really cool (easier to debug too)... the only problem would be the constant switching back and forth between the two... and say if the windows switch and the user clicks on the play window before windows switch back, output will end up in the wrong window I got the idea from NWN (Never Winter Nights) and really liked it. But, I don't think that getting the right window would be a problem. Before any output is sent, if I put the Window.Select command there should never be an error, from what I understand anyways.