Re: [hlcoders] message of bogus type
Draco wrote: I have the message registered gmsgPerfectDarkMessage = REG_USER_MSG(PerfectDarkMessage, -1); The name of the message (PerfectDarkMessage) is probably too long. There was something like a 12 character limitation in HL1. Try a shorter one, and see if that fixes it. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] ^_^ meay-meay!
-- You have won!!! password: 16347 -- [ Text.zip of type application/octet-stream deleted ] -- ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Huh?
K. Mike Bradley wrote: I do have one question. I see in the liblist.gam file there is an option for no client side dll. This means there would be no HUD? Is this doable? With no client Dll there would also be no net comms , right? So what would be the purpose? No, that means that the mod has no client.dll. Then the default client.dll of HL is used. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] For the love of god...
Slash wrote: You know what makes me hostile? When people reply with one or two sentences, but it ends up being 5 pages long because they have about 30 previous messages tagged on to the bottom. You are polluting the internet with that garbage. You're absolutely correct. When i started receiving hlcoders, i first used the Digest Mode, but that was horrible, because of this huge quotation mails. A few hours ago, someone managed to come to a quotation depth of 9 with the full texts. On Usenet this probably would have started a flamewar :) All of us should know how to quote. It's not that hard. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] For the love of god...
Jeroen ShadowLord Bogers wrote: You know what I hate? (This is more directed toward Slash.) People bitching about other people's mail style. Everyone replies to mails the way they want. If you don't like it, that's your problem. No one complains about different ways to quote. All we do is complaining about *useless* and *huge* quote contents, mainly fullquotes, like in the Deathmessages stopped working in Steam thread. Quotes are used to point out to which sentence or part of the mail the answer refers. There are enough texts about quoting, and it is pointed out clearly why some rules are useful. (for example http://www.netmeister.org/news/learn2quote.html) Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] For the love of god...
Jeroen ShadowLord Bogers wrote: And I'm saying that you shouldn't complain. Everyone has their own mailing style. If you don't like it start your own, moderated, mailinglist. But I will. I will always complain. Whenever someone talks with me and repeats anything I said I will complain. I will complain if someone talks to me and puts a small statement into a huge constellation of words. And nothing else is this bad habit of fullquoting. But this is my style! Maybe. But take this as a warning: I ignored such threads in the past, and I will ignore them in the future, because if I cannot get the point of discussion in a few seconds and have to waste a larger amount of time on reading what the current state of the thread is, I am uneager to do this. Thus I will not reply, even if i might know something important. My knowlegde may be inconsiderable, but I think I'm not the only one. Don't take this as an offence. It is just a warning. This whole list is based on voluntary help. So please take a few seconds to format your message so that is easy readable. I'm not angry or something if you don't, I simply won't read such mails. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] two quickies :)
Caleb 'Ghoul' Delnay wrote: For the MP3 it should just play. Are you sure you encoded the MP3 file properly? I have the same problem. Our mod has a startup mp3. It works for everyone but me. My Steam-HL simply does not play it. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Client side radar question
Kyle wrote: But you gota admin omega, my nazi account with your name with the swastika avatar was damn funny! It might be the fact that i'm german, but i don't see ANY fun in calling someone a nazi, in no case. Never. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] No EXPORT?
hi. It seems that since the last update of Steam the Debug Mode does not work correctly any more. I'm getting No EXPORT messages for ALL entities: Can't find address: 1b1b2ce3 ERROR: No EXPORT: func_door:LinearMoveDone (1b1b2ce3) It seems that g_engfuncs.pfnNameForFunction() always returns false. Anyone else noticed this? Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] i needed to post this; opinions please;)
Tony omega Sergi wrote: Take a look at this sexy beast http://bi.nofadz.com/hires/d_tech_opengl.jpg =D I brought back my texture loading stuff, I had an idea to get the thing to actually load hires stuff instead of just hicolor (which is what I originally Wanted to do, but then it wasn't working the way I wanted till a brainstorm) I'm very pleased with the result =D I'm capping at 1024x1024 for speed though, but I think 1024x1024 is hires compared to 512x512 max ;) Wow! That's nice work! You just broke the texture resolution engine limit. Well, it's rather a compiler than an engine limit, isn't it? We tried to solve this at BSP compile time and failed. But i guess your solution won't work with mipmaping, right? Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] i needed to post this; opinions please;)
Tony omega Sergi wrote: It's an engine AND compiler limit, because if you try to load a texture 512x512 the engine will spit it back and say its too big, it won't even try to scale it down, this is why I've limited my texture loading to 1024x1024, to kind of conform to the limits, but still be a lot above. Also my loading does MipMap as well for the sake of speed over distances. Basically you still use low-res textures in the map, and in the wad, d3d still uses the wad, OpenGL loads either Jpeg or TGA off the hard drive, provided they exist. If they don't, it uses the wad texture as usual. So the only advantage is in OpenGL, and when the hires texture exists. It uses texture compression and aniso on the hires images if the video card supports them (if we include a hi-res pack, you'll need to have a good card or it'd probably end up slow as molasses rolling up a hill in a square can in the middle of January at the south pole, or probably just crash). Course, you don't have to use 'em, I'm just providing the option =D and I think it's a nice option =D Mind you, I don't know if the aniso even works properly (haven't really tested yet, and I have a feeling it *requires* the aniso calls to be set every time the texture is bound, which I have no control over unless I render the map myself) Wow. That quite perfect :) And what about the performance? Any issues when using many of those hi-res texes? I guess not, 1024x1024 shouldn't be too large for modern graphic cards ;) Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] gamemenu.res and other various questions
Kyle wrote: valid commands: ResumeGame Disconnect OpenPlayerListDialog OpenCreateMultiplayerGameDialog OpenServerBrowser OpenOptionsDialog Quit You can extract all commands from a file inside half-life engine.gcf. Here's the list: engine ReleaseModalWindow Disconnect ResumeGame QuitNoConfirm Quit OpenChangeGameDialog OpenCreateMultiplayerGameDialog OpenLoadDemoDialog OpenServerBrowser OpenOptionsDialog OpenSaveGameDialog OpenLoadGameDialog OpenNewGameDialog OpenPlayerListDialog engine is a special command. It was described earlier. I did not test all commands, so some may not work correctly. Hope that helps. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] a sub models
mike wrote: Somewhere on this list someone said something that they had a solution to allow you have more then the default fixed numbers of sub models. does anyone know this solution? In reply to a question from me Nate 'LPlasma' Purkeypile wrote: You can alter the code to accept a far far higher submodel limit. We did this in desert crisis and have literally millions of possible combos. You just need to alter the compiler and some engine code. Email ikkyo (DC coder [EMAIL PROTECTED] ) and I'm sure he'd give you the specifics, but it definitely can be done. (And yes the default limit is 255 possible combos, # of submodels in each group multiplied against each other gives you how any you have). I did not contact him, cos we got our problem solved otherwise, so i cannot post details about the implementation. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Host_Error under Steam
Charlie Cleveland wrote: Host_Error: UserMsg: Not Present on Client 57 I might be wrong, but this 57 could be the message number. Try to find out what REG_USER_MSG() returns 57, maybe then you can find the message that causes that problem... Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Problem with dedicated server
Ravenous Bugblatter Beast wrote: Then start the game from the steam client press the toggle console key and use the connect command from the console to connect to your server by its real IP (not localhost or 127.0.0.1) That was the problem. I always tried to connect to 127.0.0.1. Now it works. Thanks! Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Problem with dedicated server
hi, I used to test my mod by starting a dedicated LAN server and then joining it, because some issues (especially related to weapon coding) are not observable on a listen server. But since Steam arrived, this seems to be no longer possible. I can start a dedicated server in LAN or Internet mode with my mod, but if i join the server, it sais Invalid STEAM UserID Ticket. I can join an server out in the net while running my dedicated server, but i cannot join my own server. I thought that directly calling hlds.exe migth fix it: D:[EMAIL PROTECTED] -game timeless -nomaster -steam +sv_lan 1 +map pt_avenger That doesn't even start a dedicated server, so i downloaded the dedicated server package and tried again. That does start a dedicated server, but i cannot join. I tried many different things, with or without SteamApp.cfg, with or without sv_lan and nomaster, nothing worked. Debugging is also impossible, because you cannot add -steam to the command line without a screwed up dedicated server window as a result: http://stud.upb.de/~q9jrieke/PT/steamdedi.jpg Any ideas? Greets, Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] clientside weapon prediction
Cortex wrote: You can use a static variable in PrimaryAttack client side. Then, you return from the function if not enough time has elapsed since your previous shot... The time parameter does not change when this is the case. And indeed, thats my workaround for now, but thats not applicable for 3 of my weapons, cos if i return when gpGlobals-time is the same as in the call before, the difference between two calls is sometimes to long. That should be fixed in the engine, mainly because the seed problem, also in other mods. That leads to another possible bug: HUD_PostRunCmd() has the parameter time. The comment above says: time is the current client clock based on prediction. But that cannot be true, because if gEngfuncs.GetClientTime() changes but this time parameter is always equal in more than two subsequent calls, can time be fully predicted? :) The next thing: If PrimaryAttack() is called several times, why the hell aren't there more than one event fired? I remember someone from Valve stating earlier that only one event per frame can be fired. This should be extended to: only one event per _predicted_ frame. IMO another bug. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] clientside weapon prediction
Jason 'Ikkyo' Gripp wrote: Client-side weapon prediction jumps around in time to re-predict miss-predictions when the client receives more accurate information from the server. Hence, an attack function can be called multiple times for the same attack. However, the animations and sounds still aren't played multiple times. To achieve for this, there is a variable called g_runfuncs. g_runfuncs is only true the first time an attack is predicted. The client looks at g_runfuncs before it decides to actually play an event. If false, then no effects. The weapon data will still be updated when g_runfuncs is false, but there should be no visible effects played. HUD_TxferPredictionData is the glue that hold the data persistence together, it transfers the data from one predicted frame to the next. The engine stores multiple frame in memory just incase if figures out something is wrong and has to go back a couple frame to correct a mistake. During these corrections, g_runfuncs is set to false so weapons don't re-fire, etc. Indeed this is a better way to detect another additional prediction frame. Just check for g_runfuncs. And i saw the checks for g_runfuncs in a few functions now, thats the reason there's no more than one event in one prediction frame. I've tried to make sense, if something is still confusing feel free to ask more questions. You made a few things clear to me, but there's one remaining question: Theses subsequent calls of PrimaryAttack() cause multiple bullets to be fired. You won't see them, cos the real bullet with the decal etc. is fired within the event function (which is called once), but m_pPlayer-FireBulletsPlayer() is called multiple times for one server side shot, and that leads to differing seed random numbers, or am i wrong? So server and client side randoms won't fit the next time? Doesn't that lead to ghost bullets? Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] clientside weapon prediction
hi, when trying to do some advanced weapon coding i discovered a strange behavior of the client weapon prediction. I'm using a counter in PrimaryAttack(). On the server everything works perfectly, but on client the counter is almost always wrong. Now here's the problem: PrimaryAttack() gets called MANY times on client when its just called once on the server. m_flNextPrimaryAttack is set in PrimaryAttack(), but on next frame it seems to be gone, m_flNextPrimaryAttack is still 0, and PrimaryAttack() gets called again! That changes not until a few frames later (maybe when the next server packet arrive?) I reproduced this what i think is a bug with an clean version of SDK2.3. Add this to hl_weapons.cpp before calling into PrimaryAttack(): gEngfuncs.Con_Printf(attack: %f\n, gEngfuncs.GetClientTime()); Take a pistol and fire once. You see many calls into PrimaryAttack(). Maybe there's something wrong with my HL? Can someone plz try to reproduce this? If this is indeed a bug, it's very bad: it makes the random_seed useless. Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
Re: [hlcoders] Visual Studio .net
Phantom wrote: I've built the SDK using the orignal VS.Net with no changes/problems iirc, but its been a while since i've done any HLMod work so not had a chance to try with VS.Net03 myself. Biggest difference between VC6 and VC.Net was the size of the dlls shrunk even under debug, which was nice :) I started working with VS.NET, but only for 2 weeks. You mention the smaller dlls, and that is in my opinion a result of a sometimes less save but more effective optimization than in VS6. I experienced one very weird bug in connection with a global var. It was a non-debug-build-only bug, and that made debugging very hard, but i'm rather convinced that this is a bug or a unsafe optimization in the compiler of VS.NET. The same code runs perfectly compiled with VS6. Or its just another faulty mem access in the SDK, who nows :) Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] HL MDL body limitation?
hi, I noticed that out mod seems to have problems with player models with many bodies/bodygroups. As soon as the number of possible body combinations becomes too great (a guess 8 is the limit), the bodies are not displayed correctly. As we use many bodygroups the number of possible combinations is much greater than 8, and the player model does not work. Could that be an engine bug or a bug in StudioModelRenderer, or is it a bug of my code? Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: HL MDL body limitation?
Its called limitations of 32bit archetecture. You can encode 8 combinations within 3 bits. And a model with 8 combinations works. But with 4 heads, 2 main bodies, 4 extensions ( == 32 possible combinations, 5 bit encoded) you are FAR from any int, byte or whatever limit, and that does NOT work. So i guess it's not an 32 bit architecture limitation. :) body seems to be a byte in the engine, for StudioModelRenderer sets it to 255 for MP hires models. I commented out that line, added a debug output, and that shows that the value set in the server dll gets to StudioModelRenderer correctly. I'm quite sure that this is an engine limitation or bug... Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Re: Yaw restriction
I need to figure out a way to restrict the players' yaw movement to a
certain cone. I slaved over my keyboard for hours trying to figure it
out with no luck. I made a little progress, but there were large
problems which could really hinder gameplay. My starting point is when
the server sends the players' view angles to the client for calculation
via the delta.lst file. The values check out, and are correct, so they
don't get mutilated when they get sent through the delta file. These
angles are sent to a global array called g_vecBipodAngles, then I tried
setting some bounds checks in the V_CalcNormalRefdef function and I
still didn't get it to work properly. is there another way to do this?
The best way is to check that i pm_shared.c. Here is some code i use in
Project Timeless:
if (...)
{
pmove-angles[YAW] = newangles ;
#ifdef CLIENT_DLL
if ( pmove-runfuncs )
{
iHasNewViewAngles = true;
VectorCopy (pmove-angles, vecNewViewAngles)
}
#endif
}
You can insert it where you want the pm-code to check the angles, for
example in the case part of MOVETYPE_WALK in PM_PlayerMove().
Rockefeller
___
To unsubscribe, edit your list preferences, or view the list archives, please visit:
http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] Scoreboard always on top
I need to have the scoreboard always on top, because of a few non-transparent menus (i.e. the team selection) i have. I already looked around and tried a few things, but it seems that the scoreboard is always in the background. Any ideas how to get it to top? Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
[hlcoders] hull file in csg
This is not a 'real' hlcoding question, but it is related... :-) When compiling your map with Zoners, you can specify a hull file. The standart hull file consists of these lines: 32 32 72 64 64 64 32 32 36 What is the meaning of these values? Is the first line the size of the player? And the third one a ducked player? And what happens to the hull(s) if you change these values? Rockefeller ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlcoders
