Code: Select all
if ( strlen(ent->model) > 1 && ent->model[0] == '*' )
{
if ( atoi(ent->model+1) > 127 )
{
G_FreeEntity(ent);
return;
}
}
Code: Select all
{ NETF(modelindex), -8 },
lol true :lol: i know he isnt asking how to bypass, is why i said "but in any case u want get working..." :lol: well, not off topicDaggolin wrote:Tr!Force, he was not asking how to "bypass" the amount of submodels on both ends, but how to solve the CM_InlineModel (bad number) error. Your last codepiece however removed all entities with subModels > 127, so that is exactly what he needs to do in a mod. I think my approach for that looked roughly like that:(shorter, but should do the same).Code: Select all
if ( strlen(ent->model) > 1 && ent->model[0] == '*' ) { if ( atoi(ent->model+1) > 127 ) { G_FreeEntity(ent); return; } }
have u looked for how jk3 (or jk2 sp) does? maybe there is a reference :/Daggolin wrote: And Tr!Force, there is no point in increasing MAX_SUBMODELS (currently 256), when only 128 (0-127) get networked anyway.
The reason why we get that overflow for the modelindex:the -8 tells the game to interpret it as signed 8 bit. If they actually made that 8 instead of -8 we could use the full 256 submodels. And when making a jk2 version with more submodels one should also increase the amount of networked bits, but that makes that version of jk2 incompatible to normal jk2. :/Code: Select all
{ NETF(modelindex), -8 },
solve this via cgame would fantastic.Daggolin wrote: I once tried to make a clientside that reads modelindex as 8-bit unsigned and my client could use the full 256 submodels, even on basejk servers trying to load those SPMaps. However some other parts of the code (like dismember) work with negative modelindex values, so changing the networking from "-8" to "8" is probably going to cause other side-effects and that's the reason we haven't done that in jk2mv.
But I had an idea for a work-around in cgame that might make the full 256 submodels usable, by assuming that negative modelindexes are overflows when loading subModels (cause negative subModels don't exist) and correcting them after getting them. Would be "hacky", but could actually work.
mvsdk? in the next 5 months? :lol: jkDaggolin wrote: If I get to try that I am probably going to include that in the mvsdk.
This is an interesting idea, I might give this a shot some time next week.Daggolin wrote:As far as I remember this is caused by the modelindex being an unsigned 8-bit integer, but getting networked as signed 8-bit integer. So any modelindex above 127 leads to an overflow and the client gets a CM_InlineModel() error./quote]
That... is really lame.
Daggolin wrote:But I had an idea for a work-around in cgame that might make the full 256 submodels usable, by assuming that negative modelindexes are overflows when loading subModels (cause negative subModels don't exist) and correcting them after getting them. Would be "hacky", but could actually work. If I get to try that I am probably going to include that in the mvsdk.
Do you need qvm compiler though? If it's just for local testing you can compile to shared libraries with msvc. Put them in your mod directory and launch jk2mvmp with "+set vm_game 0 +set vm_cgame 0 +set vm_ui 0" commandline parameters. It's actually better for development because you can use generic C debuggers.Tom Arrow wrote:I see, thanks. I downloaded TriForce's code, but the compilers he claims are in there are not actually in there, so I will have to download them separately, I suppose. Maybe I'll give that SDK thing a try.
Not yet, but Daggolin is working hard on finishing itfau wrote:Yes it's a game module not included in jk2mv I described earlier. I'm not really sure if there is any clean 1.04 source code with modern build scripts.