Hello There, Guest! Login Register


Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
expecting SHOT got SBOT
#1
Ok, what the heck does this mean?

*edit*
Ok, This error basically means that you scripted the object wrong on the server side, probably in the object.lua in the object/building/player/* directory.
Correct:
object_building_player_shared_tobin_house = SharedBuildingObjectTemplate:new {

Incorrect:
object_building_player_shared_tobin_house = SharedInstallationObjectTemplate:new {

I'm sure you could replace installation with pretty much any of the other types of building/structures, but this was my problem.
*edit*

I'm trying to add one of the newer houses to the core and got the deed just fine but it's crashing my client when I try to use the deed.

Now I have some other threads to follow on the crash (I haven't isolated it to anything in perticular yet) but... in my core log I get the SHOT / SBOT line when loading my house.iff.

#1) does it really mean anything?
#2) if it does, then what's it looking for that's different. I've compared files and VERY little is different. Unless I"m just blind which could be the case. :-)

Any idea's how to solve the SHOT problem before I waste my time trying to narrow down a client crash error?

-Duff
 
Reply
#2
Let me re-ask this another way. is there a way to bring in player houses from NGE at all? I've found places that say it's a POB issue, and others that have done it. yet I'm not seeing any obvious way to rewrite the POB, it's Completely different and I'm not understanding it. :-\

I'll keep at it, but I'm seriously curious if it's even doable for the average lite hacker.

-Duff
 
Reply
#3
Well the obvious one is that you have to rename

0004DATA to 0003DATA
And all
PRTL0005 to PRTL0004

Haven't looked deeper than that, structure seems to be the same otherwise.
 
Reply
#4
the POB file is definately a different format. I"m guessing based on the POB file notes on these forums that the type 3 POB's use folders and indexes for the Verts, where as the type 1's & 2's don't have any subfolders.

I renamed all the nodes I could find that were different, I reworked the POB to look like a standard large corellia house (using the bunker data, corellia house format), but the client still crashes. It will take some time to narrow down if it's the POB causing the crash, or the IFF or shader, or whatever.

For the time being if I replace the Bunder data with the corellia house data, leaving everything else the same I still get the sbot / shot error, which tells me it's not the house iff causing the issue but something downstream. Simply renaming the corellia house, and not loading any additional assets should work just fine, so by loading the additional assets something is getting borked.

Sure would be nice if Uli would enlighten us, or whoever is working on it, but we'll get it. I hope.

-Duff
 
Reply
#5
Ok, so i'm starting from scratch and trying to be methodical in my approach. What's killing me tho is right out of the gate I'm running into an unexpected problem I can't seem to fix.

I started clean. I copied the shared_player_house_generic_small_style_01.iff and named it shared_player_house_mustafar_lg.iff. Keeping the names the same so it matches with the CRC tables I had already modified. So I have a new IFF that's the same as the existing iff in all but name (no structure changes within the IFF).

The core scripts had already been modified, and shouldn't need to be changes. They're pointing to the mustafar house in object.lua, then refactoring it (removing the share_ and setting some default values) in the player_house_mustafar_lg.lua file. Serverobjects doesn't change either. None of the path's to the IFF's needs to change because I maintained the naming structure.

I did the same process for the deed (as listed above) just to make sure I rooted out all post 14.1 BS.

The deed generates fine, I can get the place structure screen with the mesh and green squares fine, and the mesh looks like the generic style 1. But when I place it the core goes whacko. First it says it can't find the footprint, then it says it can't generate the object with CRC xxx and then obviously the final fail to generate object. All the paths in the error line up with existing files that I know (and confirmed) are in the .tre files...

I'm at a loss. This should work. No type-o's. No flubbs that I can find.

Also, I can spawn a style 1 generic fine using a frog, and I even went back to the core scripts and changed my deed to spawn the generic style 1 directly and it worked just fine. so it's something to do with how the core is handling the new object even though it's the same as the old object...

frustrating.

-Duff
 
Reply
#6
(2013-11-20, 03:28 PM)duffstone Wrote: the POB file is definately a different format.

No there not, there is only one slight difference which causes the crashes and that change was to make the file structure follow how it should of been in the first place.

Thats a big hint.
[Image: 2156b479.gif]
 
Reply
#7
Well I appreciate the help/hint. It will all start to make sense in time, right now I'm just too green to understand it all without a bunch of fail, rince, repeat cycles. :-)

I think the troubles I was having with whacky wild unexpect stuff happening was tre file versioning. I was working on my laptop at work and I haven't gotten it setup for proper development yet.
 
Reply
#8
ok, despite the head cold I think I'm making progress. All my other peculiarities I was experiencing were caused by the CORE me inadvertently trying to use an installation object instead of a house object. (I wasn't trying to to it, I just copied the wrong entity and didn't notice). So anyway I'm making deeds and placing renamed existing 14.1 structures at will. So the coding & tre file construction side of it is now understood.

Now I'm working on the POB file. I believe I know what I need to (rename the nodes, and make sure the vert coords are stated counter-clockwise), But I'm lacking a tool that will allow me to efficiently pull the hex data out of the file as Hex values. My pastes keep tying to convert it into ascii or something else. I just want the regular hex long values as they appear in the editors "04 AF D0 11". <--- that.

Not the wierd ascii interpretation of it. Any of you guys come across a tool that will do that? I'm using FrHed as my hex editor but I'm open to something more effective if you have something.

-Duff

P.S. I would be willing to pay for a good one that would be fully featured. I just don't know much about them would like some advice.
 
Reply
#9
I use Hex Workshop, Uli uses HxD, but it really comes down to preference.

Make sure you target/select the bytes (hex values) instead of the actual ASCII translation. TreExplorer will copy the ASCII regardless though.

Also...

Floats and most of the ints are reversed, so you'll need to manually reverse them, always go by 2 bytes.

Example float:
The number 2 = 40 00 00 00 in bytes, normally. In SWG, it would be 00 00 00 40.

I don't know of any program that reverts bytes of the top of my head, besides actually coding it into a program (like I have to do for the mod tools).

By the way, no idea if you know this, but as a general tip, replace strings (ASCII type stuff, like sample/music_theme.wav) in treExplorer, because it'll automatically fix the chunk size, otherwise you'd have to edit it in manually edit the 4 bytes following a Chunk/FORM name as a reversed integer. This is, because if you edit/paste in a name that's longer than the original one, the chunk size won't match and the game won't read it right, or if you open it in treExplorer, it'll split the different chunks wrongly.
 
Reply
#10
What I'd love to know is how you figured all this out. How do you know a number is a long or a float? I know that's a loaded question and time fills all gaps in knowledge but still. :-) I'm guessing that the xyz in the verts in the POB are floats and not longs, but ultimately I don't think it matters as long as the bytes get moved into the right order counter-clockwise order.

-Duff
 
Reply
  



Forum Jump:


Browsing: 1 Guest(s)