Tels
-
Posts
14984 -
Joined
-
Last visited
-
Days Won
23
Posts posted by Tels
-
-
That string isn't in our libraries or engine or DLL, so I guess it's coming from one of the linux libs.
I doubt there's much we can do about this, unless some Linux expert wants to step in here and offer some advice.
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.
-
Are you sure about this, I am fairly sure that hidden side of and FS are still rendered so it good practice to caulk them.
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.
-
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.
-
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
-
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.
-
Well after 3 interviews, I didn't get the role. Apparently I was to senior from an exp. and skill point of view.
Wtf... their loss.
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
-
I've added a possible patch for bug http://bugs.thedarkmod.com/view.php?id=3968to the tracker.
-
Anderson, on 04 Jan 2015 - 3:54 PM, said:
Will there be Romanian language?
It looks like it's there, but it's missing characters.
@SteveL?
@Tels?
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.
-
Sent a PM since its not accessible to me.
-
Cool - sorry for the late reply, holidays and stuff
-
I'm up for Linux testing, if it is still needed.
-
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"?
-
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.)
-
The gameplay issue at ... um... issue IMO is that after a player has KO'd all the AI in a level, they can prance around with impunity and it's not much of a stealth game anymore, at least for the zones the player has already passed, making them gameplay deadzones.
There are different solutions to this. One is bringing KO'd AI back. Another is for mappers to make new areas with new AI open up throughout the whole mission time, which either AI can somehow make it back to the deadzones or the FM is designed to never go back, only ever forwards. Another is to spawn in new AI or otherwise get new AI into old areas.
None of them is ideal, but the second solution is probably the best way to deal with the problem. The others open up bigger problems, and are more like hacks to fix what's really a mission design issue that should have avoided the problem to begin with.
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).
-
Another idea I haven't seen explored is Ai "waking up" other AI they find
I don't see why there is any concern over whether or not some players decide to blackjack all of the AI and explore the level at their leisure. How does that affect you or I?
If they're successfully clearing a mission of all AI by blackjacking them then they must already be playing stealthily. I see no reason to enforce more stealth related activities if they've already invested their time stalking the AI, and carefully removing them without alerting anyone. It's a perfectly valid way to play.
If individual mappers want to do that, dandy but as has been explained many times over...the reward of the blackjack is that it is a stealthy, silent, non-lethal way to remove AI form the playing field. That's the reward. I feel waking the AI sends the wrong message and punishes the player for not 'permanently' removing those AI by killing them.
Waking the AI is an idea but I don't think it meshes well within TDM.
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
-
If mappers don't want players to blackjack guards they can always give them elite helmets, or at the extreme, take away the player's blackjack.
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.
-
There is still no new gameplay created...the player is not going to behave any differently with this feature added (with the exception of possibly killing unconscious guards). With random patrols, a player never knows for sure whether an area is totally clear, unless they're in a completely contained area. And if that's the case then no AI could get in to wake anyone up.
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.
-
We have new guards replacing Ko'd ones in Thief FM's when a certain goal has been completed.
Sure, but thats only in a few selected FMs. And it is very predictable (after you played it once).
-
Not at all. A lot of time went into designing rules that discourage players from killing. Killing is noisier (more chance of alerting someone) and messier (the blood left behind can also alert guards if they see it). Also, the blackjack can bypass most forms of armour, which is more difficult with the arrows or sword. While one hit with the bj can still KO an alert guard (as long as they don't have a helmet), one arrow or sword strike is generally not enough to kill them in that state. The tools for killing (sword or arrows) also make the player more visible, while the BJ does not.
All those rules combine to encourage the player to rely on nonlethal take downs.
The only difference is that there is one extra guard involved in the search (assuming he can)...how does that create a new situation? The player is likely to be long past that area by the time the body is discovered, but even if he's not, how is new gameplay created by 5 guards searching instead of 4?
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:
does not change gameplay in any way eitheris 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).
-
Metal Gear Solid games have also done this for as long as I remember.
Would not really enjoy this feature in TDM, as I'm the kind of guy who usually conks out every guard, stacks the bodies and then enjoys poking around at a leisurely pace
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.
-
Fan Mission #48: A Score to Settle, by Springheel (2011/07/01)
Can't click that link and go anywhere maybe because of the # sign? Anyone have issue loading that page?
I'm getting: "The page isn't redirecting properly."
Which is odd considering I found the thread in the New Content section after someone had posted in it. If it loaded for them, why wouldn't it load for anyone else.
See http://forums.thedarkmod.com/topic/16802-new-forum-bugs/?do=findComment&comment=361519
-
It doesn't appear to like the # character. Looking at the web server config files now to see if I can resolve this.
# 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.
-
Ah, thank you, now I get the gist of it. Personally, I would have preferred if I could have fiddled around with the specific language file, but as long as I can get it to work via the "all" file as well, I don't mind. I would have preferred to work on that specific language file for safety reasons: Even if I mess up something in "all", I won't have to keep constantly replacing it with a backup copy again, just to get things working. Either way, I'm sure I'll get the hang of it and manage.
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!
-
Oh, one more thing: Is it enough if I just edit the slovak.lang file ?
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
Looking at it now in Notepad++, I can clearly see where the few auto-translated lines are from, while the vast majority of the text is still in English.
As a test run of the translated file, I'll write the GUI features without diacritics at first, then eventually add them once I consult the wiki in a more in-depth way. I want to avoid more serious problems with unrecognised letters.
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!
Posix_QueEvent: overflow in Vengeance for a Thief Part 1
in TDM Tech Support
Posted
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).