Jump to content
The Dark Mod Forums

Tels

Member
  • Posts

    14984
  • Joined

  • Last visited

  • Days Won

    23

Everything posted by Tels

  1. It are indeed keyboard, or console events. And a quick look through the code shows that the ptr seems to be always NULL, except for some cases on win32 (which also empties the queue without freeing the memory in these ptrs).
  2. It comes from here: sys/posix/posix_main.cpp 273: common->Printf( "Posix_QueEvent: overflow\n" ); MAX_QUED_EVENTS is set to 256. Either it could be raised (512? 1024?), or we need to see why events are dropped. If it is performance related, then events can be dropped if the system receives them faster than it can handle them, and 512 or 1024 might not help much. Interestingly enough the code does not saywhat these events are (keyboard? mouse? joystick?) ,and also this is suspicious: /* ================ Sys_ClearEvents ================ */ void Sys_ClearEvents( void ) { eventHead = eventTail = 0; } Events can contain data, emptying the queue like this would leak memory if there are events with data that is not freed.
  3. It becomes especially important if these faces can cast shadows or generate AAS. If you have a brush-face from a column flush with the floor, the brush face will be removed during dmap. Not so if you turn the column into a func_static. In this case the bottom of the column will cast a shadow into the floor, which wil always be invisible, but stil has to be computed. If you caulk that face, the shadow is not cast. Scenes with moving lights will generate a much greater impact on performance than the same scene with static (or no) lights.
  4. setGUIParm and setGUIFloat should be doing what you want, it sets the key "xyz" to the value "foo" (or 1.0). getGUIParm works the reverse, given the GUI index number (which you get when you create the GUI, it is basically a handle), and a key like "xyz", you get the value back. To see an example, look at tdm_message.gui - it contains references to "gui::mdg_text" (the variable is visible outside the GUI as "msg_text", not sure if "gui::msg_text" would also work). Its value will be transfered to the "text" property of the "message" window on load of the GUI in the onTime 0 block. You could use any other value and manipulate any other value, like foreground color, font etc etc.
  5. I'm not sure the "inherit target_null" will be working. Maybe try: entity atdm:ai_spider_thin { "hide" "1" } -------------- Btw, I can relate to your fear, albeit for me it was the "floating eyes and shadow" in the Gatehouse. Almost couldn't play it in the evening with the dark room and so on... creepy! OTOH, "getting very uncomfortable" is just a strong reaction - and I'm not sure that just hiding the source of fear will really help - I mean, it basically removes the source for the emotion - but if you remove all things that you fear, or hate, or feel uncomfortable with, then its no longer a dark, dangerous world, but more like Tetris
  6. Do these help: // TODO: load data from an XD file // set the number of lines: $player1.setGuiInt(gui, "msg_lines", getIntKey("lines")); // set the text for the GUI $player1.setGuiStringFromKey(gui, "msg_text", self, "text"); // set number of lines $player1.setGuiInt(gui, "msg_lines", getIntKey("lines")); ? I'm not sure if "setGUIInt" etc are available in your engine.
  7. Oh man, that sucks! On the plus side, this is a compliment, and maybe in the future, they have uses for you. Never say never and never burn bridges. Maybe in half a year they need more people, or find out the "other candidate" wasn't skilled enough. I'd contect them in a view months and ask again. Cost you nothing and we all know how your life depends on good underground contacts
  8. I've added a possible patch for bug http://bugs.thedarkmod.com/view.php?id=3968to the tracker.
  9. Anderson, on 04 Jan 2015 - 3:54 PM, said: The translation of the strings was done by Anderson, converted to a patch by me and committed by SteveL (Thank you both!) http://bugs.thedarkmod.com/view.php?id=3869 I've added the nec. character definitions to the charset: http://wiki.thedarkmod.com/index.php?title=I18N_-_Charset But all fonts (TDM uses bitmap fonts!) are still missing the special characters, and somebody would have to paint them on the bitmaps for every font and size, in case the font has still more than one size. Most fonts only use the biggest size (and let the engine scale the letters down). However, we still have a few dozend fonts or so. And the work is mindnumbing and tiresome and takes hours. Since 1.08 (or so), not a single character was added to any font, so I doubt it will happen for 2.03. Sorry.
  10. Sent a PM since its not accessible to me.
  11. Cool - sorry for the late reply, holidays and stuff
  12. I'm up for Linux testing, if it is still needed.
  13. Forgot: Converting the game time to "hh:mm" is a bit tricky, too. Do you need the real time, or the "time since start of mission"?
  14. You need to: * create a GUI file that has a string for display * use a script with setGuiString() to update it with a loop around a sys.wait(1.0) Updating it only when the player is in view is a bit more tricky, but it might not be nec. The TDM message script contains an example for an onscreen message but I think attaching the GUI to an entity should be no problem, either. (I guess that this is what you want to do as you said "player view". An onscreen message would always be in view for the player.)
  15. I have to agree with the first sentences, these sum up the "issue" for me perfectly. For the solution, well, yeah, that's the idea about this brainstorming. If there was no issue, no change would be required, and if no (or for the worse) change is brought, the issue isn't solved, either. Edit: And I do have to draw parallels to the relighting here, too. The implementation does not rely on the mappers (but they can change it), and it helps the "I put out all lights and now I'm dancing around the AI in the dark" issue that crops up. The issues isn't really that a mission becomes easier you longer you play it (which it should) but that the mission becomes too easy too fast. With each guard down, with each light out and each door unlocked, the difficulty really plummes down. (It is not linear is what I mean).
  16. Another idea I haven't seen explored is Ai "waking up" other AI they find One could make the very same arguments for relighting of torches and candles - and well, it was implemented. I see "waking AI up" mesh very well with TDM if it is implemented in the right fashion. (e.g. it doesn't force the player to kill) It might f.i. be an option for hard-core players. Or it might be of the variety "AI can wake up other AI in limited circumstances (blackjack not that long ago, AI is found when player is near)". The latter idea has not yet be explored, I think. Edit: fixed grammer in first sentence. Sorry
  17. But both are FM specific (it won't work f.i. in Saint Lucia) and rather radical options. It is like forbidding to kill guards or not giving the player any weapons. Sure, that stops the killing spree, but is still not desired by the players.
  18. Uhm, how does the game play not change, when there is a player behaviour change? (undesirable change) Either the player kills guards (desirable change) or he doesn't (it might be forbidden, or he doesn't do it), so the guards wake up and cause the player trouble (avoid AI) (no change): the guard wakes up, but the player is too far to notice How can you claim there is no game play change when 2 out of 3 possibilities change the player behaviour? Wether the change is desirable or not is a different matter, but to claim it makes no difference is quite strange.
  19. Sure, but thats only in a few selected FMs. And it is very predictable (after you played it once).
  20. As I said, if you watch playthroughs, most player whack every guard, then roam the place freely. If one gaurd wakes up again - 0 vs. 1 guard does make a difference. Esp. in some areas 1 vs 2 gaurds will make a difference, too. More specifically I argue that: is not true in the general sense. If guards wake up and resume their patrols (or alert somebody), then this changes game play as the player needs continously to be more alert (a "new" guard could come around the corner in an otherwise empty area). This is IMO the same with relighting torches. Suddenly a safe area (dark) becomes unsafe again, and this happens at a more or less random time: gaurd approaches torch and maybe lights it, it is not entirely predictable by the player when or if it will happen. The issue about "well, then lets make sure he stays down" applies, tho. Maybe a hybrid solution could work: * normal blackjacked guards might wake up, and cause a ruccus later (could also start searching (this causes danger that they discover other bodies) * player needs to do something to prevent this (besides kill), like putting a small dose of "sleep-o-well herbs"? to the guard. If applied, the guard stays down longer (forever in gameplay time), if not, the guard might wake-up soemtimes later. The new item would put both a limit on the permanently-down guards, it would also be different for each difficulty level (10 does for easy, 7 for medium, 2 for hard or whatever the author uses) and it could be found in game (meaning it is only available later in the mission). And the player could decide when to use it. Or skip it and live with the danger (a guard waking up in a remote location does not matter).
  21. OTOH, in playthroughs you often see people whack _every_ guard they see, most often as soon as they encounter them. This makes for a bit boring play, esp. later on when most of them are already hidden under the stairs. Sure, you can now look into every corner, but its still boring - there is no danger anymore. A lo of missions are designed so that you need to sneak aorund the guards and their patrol routes, if you whack the AI the first time you encounter him, you have robbed yourself of the possibilities and the mission becomes a LOT easier. And there is (almost never) penatly to a a successful blackjack attempt - and unsuccessful ones just lead to "load and try again". Compare this to water arrows (limited amount) or kills (either forbidden, which is a bit to strict for me, or very hard to do). So, I can see how having either guards wake up, or a limit on blackjacks would make FMs more interesting and harder. Both solutions have drawbacks, tho. The wake-up is already covered by Springheel's and other posts. The "BJ limit" shares the problems of all limits - how is the player suppossed to know when he can/should use "one slot" up? With a limit of say 5 BJs, how do you know that you won't encounter 4 important guards later? (The same goes with water arrows etc, but here the limits have alreay been accepted) What my post here is trying to say is that unlimited, easy-to-do and no penalty blackjacks lead to a certain play style, which bypasses sometimes the intent of the FM author. And this might be something that should be a amended a bit. Technical problems must be solved, of course.
  22. See http://forums.thedarkmod.com/topic/16802-new-forum-bugs/?do=findComment&comment=361519
  23. # in URLs are not sent to the server, they denote an "anchor", and the anchor part is kept client-side and used to access the first href with that name. So the server only sees the part up to the "#" character, which is probably an incomplete URL for it. Hence the loop or error.
  24. Just for the translation, you can also work on the specific .lang file, if that is easier. It has then to be merged back in by me, but that is certainly doable. One thing to watch our for are comments - the all.lang file often contains hints for translators, while the autogenerated .lang file misses these, so if you are unsure about the translation, look into the all.lang file - or ask here Thank you!
  25. No, the xyz.lang files are generated automatically from the all.lang file (they need to be in the right encoding and a script checks all entries). Please only edit all.lang That sounds good For testing, you can also edit the slovak.lang file - afterwards I would then have to merge the changes back into all.lang. It is certainly doable, but more work Thank you in advance!
×
×
  • Create New...